On-disk file format for a serverless distributed file system

ABSTRACT

A file format for a serverless distributed file system is composed of two parts: a primary data stream and a metadata stream. The data stream contains a file that is divided into multiple blocks. Each block is encrypted using a hash of the block as the encryption key. The metadata stream contains a header, a structure for indexing the encrypted blocks in the primary data stream, and some user information. The indexing structure defines leaf nodes for each of the blocks. Each leaf node consists of an access value used for decryption of the associated block and a verification value used to verify the encrypted block independently of other blocks. In one implementation, the access value is formed by hashing the file block and encrypting the resultant hash value using a randomly generated key. The key is then encrypted using the user&#39;s key as the encryption key. The verification value is formed by hashing the associated encrypted block using a one-way hash function. The file format supports verification of individual file blocks without knowledge of the randomly generated key or any user keys. To verify a block of the file, the file system traverses the tree to the appropriate leaf node associated with a target block to be verified. The file system hashes the target block and if the hash matches the access value contained in the leaf node, the block is authentic.

RELATED APPLICATION(S)

This is a continuation of U.S. patent application Ser. No. 09/814,259,entitled “On-Disk File Format for a Serverless Distributed File System”,which was filed Mar. 21, 2001, and is assigned to Microsoft Corporation.

TECHNICAL FIELD

This invention relates to serverless distributed file systems, andparticularly to formats of files stored in serverless distributed filesystems.

BACKGROUND

File systems manage files and other data objects stored on computersystems. File systems were originally built into a computer's operatingsystem to facilitate access to files stored locally on resident storagemedia. As computers became networked, some file storage capabilitieswere offloaded from individual user machines to special storage serversthat stored large numbers of files on behalf of the user machines. Whena file was needed, the user machine simply requested the file from theserver. In this server-based architecture, the file system was extendedto facilitate management of and access to files stored remotely at thestorage server over a network.

One problem that arises in distributed file systems concerns storage ofidentical files on the server. While some file duplication normallyoccurs on an individual user's personal computer, duplicationunfortunately tends to be quite prevalent on networks where a servercentrally stores the contents of multiple personal computers. Forexample, with a remote boot facility on a computer network, each userboots from that user's private directory on a file server. Each privatedirectory thus ordinarily includes a number of files that are identicalto files on other users' directories. Storing the private directories ontraditional file systems consumes a great amount of disk and server filebuffer cache space. From a storage management perspective, it isdesirable to minimize file duplication to reduce the amount of wastedstorage space used to store redundant files. However, any such effortsneed to be reconciled with the file system that tracks the multipleduplicated files on behalf of the associated users.

To address the problems associated with storing multiple identical fileson a computer, Microsoft developed a single instance store (SIS) systemthat is packaged as part of the Windows 2000 operating system. The SISsystem reduces file duplication by automatically identifying commonidentical files of a file system, and then merging the files into asingle instance of the data. One or more logically separate links arethen attached to the single instance to represent the original files tothe user machines. In this way, the storage impact of duplicate files ona computer system is greatly reduced.

Today, file storage is migrating toward a model in which files arestored on various networked computers, rather than on central storageserver. The serverless architecture poses new challenges to filesystems. One particular challenge concerns managing files that aredistributed over many different computers in a manner that allows a userto quickly access a file, verify that it is indeed the requested file,and read/write that file, all while insuring that the files are storedand accessed in a secure way that prevents access by non-authorizedusers.

The invention addresses these challenges and provides solutions that areeffective for distributed file systems, and in particular, serverlessdistributed file systems.

SUMMARY

A file format for a serverless distributed file system is composed oftwo parts: a primary data stream and a metadata stream. The data streamcontains a file that is divided into multiple blocks. Each block isencrypted using a symmetric cipher (e.g., RC4) and a hash of the blockas the encryption key. The metadata stream contains a header, astructure for indexing the encrypted blocks in the primary data stream,and some user information.

The indexing tree structure defines leaf nodes for each of the blocks.Each leaf node consists of an access value used for decryption of theassociated block and a verification value used to independently verifythe encrypted block independently of other blocks. In oneimplementation, the access value is formed by hashing the file block andencrypting the resultant hash value using a symmetric cipher and arandomly generated key. The key is then encrypted using an asymmetriccipher (e.g., RSA) and the user's public key as the encryption key. Theverification value is formed by hashing the associated encrypted blockusing a one-way hash function (e.g., SHA).

Depending on the size of the file, the indexing structure may includeintermediate nodes formed by grouping the leaf nodes into tree blocksand computing hash values of each tree block. These intermediate nodescan again be segmented into blocks and each block hashed to form thenext nodes. This can be repeated as many times as desired until reachinga root node. The root node is then hashed, and the hash value is usedalong with the metadata header and user information to produce averification value for the entire file. In one implementation, thewhole-file verification value is signed with a user's signature.Alternatively, a file may be constructed without such signatures.

The file format supports verification of individual file blocks withoutknowledge of the randomly generated key or any user keys. To verify ablock of the file, the file system optionally evaluates the signature onwhole file verification value (if one exists), checks that thewhole-file verification value matches the hash of the root block,metadata header and user information and then traverses the tree to theappropriate leaf node associated with a target block to be verified. Thefile system hashes the target block and if the hash matches the accessvalue contained in the leaf node, the block is authentic.

The file format further supports reading from and writing to individualblocks without interfering with other blocks. The file format is alsoconducive for sparse files that have vast areas of non-data.

BRIEF DESCRIPTION OF THE DRAWINGS

The same numbers are used throughout the document to reference likecomponents and/or features.

FIG. 1 is an illustration of a networked computing system thatimplemented a serverless distributed file system.

FIG. 2 is a block diagram of logical components implemented at each ofthe computers in the computing system of FIG. 1.

FIG. 3 is a block diagram of a computer that may be used to implement acomputer in the computing system of FIG. 1.

FIG. 4 illustrates a file format for a file stored in the serverlessdistributed file system. The file format includes a data stream and ametadata stream.

FIG. 5 shows a file that is segmented and encrypted to form the datastream of the file format.

FIG. 6 shows an indexing structure to index the file segments. Theindexing structure forms part of the metadata stream.

FIG. 7 illustrates a user key list that identifies users with privilegesto access the file.

FIG. 8 is a flow diagram of a process for constructing a file accordingto the file format of FIG. 4.

FIG. 9 is a flow diagram of a process for verifying individual blocks ofthe file.

FIG. 10 is a flow diagram of a process for reading individual blocks ofthe file.

FIG. 11 is a flow diagram of a process for writing to a file block.

FIG. 12 is a flow diagram of a process for producing a signed manifestof changes made to one or more files.

FIG. 13 illustrates a signed manifest and exemplary contents therein.

DETAILED DESCRIPTION

The following discussion is directed to a file format used in adistributed file system, and to techniques for managing access to andverification of files using the file format. The file system isdescribed in the context of a symbiotic, serverless, distributed filesystem that runs on multiple networked computers and stores files acrossthe computers rather than on a central server or cluster of servers. Thesymbiotic nature implies that the machines cooperate but do notcompletely trust one another.

The file system does not manage the storage disk directly, but ratherrelies on existing file systems on local machines, such as those filesystems integrated into operating systems (e.g., the Windows NT® filesystem). The file system described herein assumes a level at whichmulti-stream files can be stored as the underlying local storage model.

While the file system is described in the context of storing “files”, itshould be noted that other types of storable data can be stored in thefile system. The term “file” is used for discussion purposes and isintended to include data objects or essentially any other storagesubject matter that may not be commonly characterized as a “file”.

Serverless Distributed File System

FIG. 1 illustrates an exemplary network environment 100 that supports aserverless distributed file system. Four client computing devices 102,104, 106, and 108 are coupled together via a data communications network110. Although four computing devices are illustrated, different numbers(either greater or fewer than four) may be included in networkenvironment 100.

Network 110 represents any of a wide variety of data communications 19networks. Network 110 may include public portions (e.g., the Internet)as well as private portions (e.g., an internal corporate Local AreaNetwork (LAN)), as well as combinations of public and private portions.Network 110 may be implemented using any one or more of a wide varietyof conventional communications media including both wired and wirelessmedia. Any of a wide variety of communications protocols can be used tocommunicate data via network 110, including both public and proprietaryprotocols. Examples of such protocols include TCP/IP, IPX/SPX, NetBEUI,etc.

Computing devices 102-108 represent any of a wide range of computingdevices, and each device may be the same or different. By way ofexample, devices 102-108 may be desktop computers, laptop computers,handheld or pocket computers, personal digital assistants (PDAs),cellular phones, Internet appliances, consumer electronics devices,gaming consoles, and so forth.

Two or more of devices 102-108 operate to implement a serverlessdistributed file system. The actual devices included in the serverlessdistributed file system can change over time, allowing new devices to beadded to the system and other devices to be removed from the system.Each device 102-108 that is part of the distributed file system hasportions of its mass storage device(s) (e.g., hard disk drive) allocatedfor use as either local storage or distributed storage. The localstorage is used for data that the user desires to store on his or herlocal machine and not in the distributed file system structure. Thedistributed storage portion is used for data that the user of the device(or another device) desires to store within the distributed file systemstructure.

In the illustrated example of FIG. 1, certain devices connected tonetwork 110 have one or more mass storage devices that include both adistributed portion and a local portion. The amount allocated todistributed or local storage varies among the devices. For example,device 102 has a larger percentage allocated for a distributed systemportion 120 in comparison to the local portion 122; device 104 includesa distributed system portion 124 that is approximately the same size asthe local portion 126; and device 106 has a smaller percentage allocatedfor a distributed system portion 128 in comparison to the local portion130. The storage separation into multiple portions may occur on a perstorage device basis (e.g., one hard drive is designated for use in thedistributed system while another is designated solely for local use),and/or within a single storage device (e.g., part of one hard drive maybe designated for use in the distributed system while another part isdesignated for local use). The amount allocated to distributed or localstorage may vary over time. Other devices connected to network 110, suchas computing device 108, may not be part of the distributed file systemand thus do not have any of their mass storage device(s) allocated foruse by the distributed system. Hence, device 108 has only a localportion 132.

A distributed file system 150 operates to store one or more copies offiles on different computing devices 102-106. When a new file is createdby the user of a computer, he or she has the option of storing the fileon the local portion of his or her computing device, or alternatively inthe distributed file system. If the file is stored in the distributedfile system 150, the file will be stored in the distributed systemportion of the mass storage device(s) of one or more of devices 102-106.The user creating the file typically has no ability to control whichdevice 102-106 the file is stored on, nor any knowledge of which device102-106 the file is stored on. Additionally, replicated copies of thefile will typically be saved, allowing the user to subsequently retrievethe file even if one of the computing devices 102-106 on which the fileis saved is unavailable (e.g., is powered-down, is malfunctioning,etc.).

The distributed file system 150 is implemented by one or more componentson each of the devices 102-106, thereby obviating the need for anycentralized server to coordinate the file system. These componentsoperate to determine where particular files are stored, how many copiesof the files are created for storage on different devices, and so forth.Exactly which device will store which files depends on numerous factors,including the number of devices in the distributed file system, thestorage space allocated to the file system from each of the devices, howmany copies of the file are to be saved, a cryptographically securerandom number, the number of files already stored on the devices, and soon. Thus, the distributed file system allows the user to create andaccess files (as well as folders or directories) without any knowledgeof exactly which other computing device(s) the file is being stored on.

The files stored by the file system are distributed among the variousdevices 102-106 and stored in encrypted form. When a new file iscreated, the device on which the file is being created encrypts the fileprior to communicating the file to other device(s) for storage. Thedirectory entry (e.g., the file name) for a new file is alsocommunicated to the other device(s) for storage. Additionally, if a newfolder or directory is created, the directory entry (e.g., folder nameor directory name) is also communicated to the other device(s) forstorage. As used herein, a directory entry refers to any entry that canbe added to a file system directory, including both file names anddirectory (or folder) names.

The distributed file system 150 is designed to prevent unauthorizedusers from reading data stored on one of the devices 102-106. Thus, afile created by device 102 and stored on device 104 is not readable bythe user of device 104 (unless he or she is authorized to do so). Inorder to implement such security, the contents of files as well as alldirectory entries are encrypted, and only authorized users are given thedecryption key. Thus, although device 104 may store a file created bydevice 102, if the user of device 104 is not an authorized user of thefile, the user of device 104 cannot decrypt (and thus cannot read)either the contents of the file or its directory entry (e.g., filename).

File Encryption

The files are encrypted using a technology known as “convergentencryption”. Convergent encryption has the following two properties.First, if two or more encryptable objects are identical, then even ifdifferent encryption keys are used to encrypt them to provide individualcipher objects, one does not need to have access to any of theencryption keys to determine from an examination of the cipher objectsthat the encryptable objects are identical. Second, if two or moreencryptable objects are identical but are encrypted with differentencryption keys, the total space that is required to store all of thecipher objects is proportional to the space that is required to store asingle encryptable object, plus a constant amount of storage for eachdistinct encryption key.

Generally, according to convergent encryption, a file F (or any othertype of encryptable object) is initially hashed using a one-way hashingfunction h (e.g., SHA, MD5, etc.) to produce a hash value h(F). The fileF is then encrypted using a symmetric cipher (e.g., RC4, RC2, etc.) withthe hash value as the key, or E_(h(F))(F). Next, read access controlentries are created for each authorized user who is granted read accessto the encrypted file. Write access control is governed by the directoryserver that stores the directory entry for the file, and it is thus notaddressed by the file format and is not discussed further within thisdocument. All references to “access” within this document refer to readaccess. The access control entries are formed by encrypting the file'shash value h(F) with any number of keys K₁, K₂, . . . , K_(m), to yieldE_(K1)(h(F)), E_(K2)(h(F)), . . . , E_(Km)(h(F)). In one implementation,each key K is the user's public key of a public/private key pair for anasymmetric cipher (e.g., RSA).

With convergent encryption, one encrypted version of the file is storedand replicated among the serverless distributed file system 150. Alongwith the encrypted version of the file is stored one or more accesscontrol entries depending upon the number of authorized users who haveaccess. Thus, a file in the distributed file system 150 has thefollowing structure:[E_(h(F))(F), <E_(K1)(h(F))>, <E_(K2)(h(F))>, . . . , <E_(Km)(h(F))>]

One advantage of convergent encryption is that the encrypted file can beevaluated by the file system to determine whether it is identical toanother file without resorting to any decryption (and hence, withoutknowledge of any encryption keys). Unwanted duplicative files can beremoved by adding the authorized user(s) access control entries to theremaining file. Another advantage is that the access control entries arevery small in size, on the order of bytes as compared to possiblygigabytes for the encrypted file. As a result, the amount of overheadinformation that is stored in each file is small. This enables theproperty that the total space used to store the file is proportional tothe space that is required to store a single encrypted file, plus aconstant amount of storage for each additional authorized reader of thefile.

For more information on convergent encryption, the reader is directed toco-pending U.S. patent application Ser. No. 09/565,821, entitled“Encryption Systems and Methods for Identifying and Coalescing IdenticalObjects Encrypted with Different Keys”, which was filed May 5, 2000, inthe names of Douceur et al., and is commonly assigned to MicrosoftCorporation. This application is hereby incorporated by reference.

Computing Device Architecture

FIG. 2 illustrates logical components of an exemplary computing device200 that is representative of any one of the devices 102-106 of FIG. 1that participate in the distributed file system 150. Computing device200 includes a server component 202, a client component 204, a memory206, a mass storage device 208, and a distributed file system interface210. Computing device 200 also typically includes additional components(e.g., a processor), however these additional components have not beenshown in FIG. 2 so as not to clutter the drawings. A more generaldescription of a computer architecture with various hardware andsoftware components is described below with reference to FIG. 3.

Memory 206 can be any of a wide variety of conventional volatile and/ornonvolatile memories, such as RAM, ROM, Flash memory, and so on. Massstorage device 208 can be any of a wide variety of conventionalnonvolatile storage devices, such as a magnetic disk, optical disk,Flash memory, and so forth. Mass storage device 208 is partitioned intoa distributed system portion and a local portion.

Computing device 200 is intended to be used in a serverless distributedfile system, and as such includes both a server component 202 and clientcomponent 204. Server component 202 handles requests when device 200 isresponding to a request involving a file or directory entry stored (orto be stored) in storage device 208, while client component 204 handlesthe issuance of requests by device 200 for files stored (or to bestored) in the distributed file system. Client component 204 and servercomponent 202 operate independent of one another. Thus, situations canarise where the serverless distributed file system 150 causes filesbeing stored by client component 204 to be stored in mass storage device208 by server component 202.

Client component 204 includes a storage and retrieval control module220, which along with interface 210, manages access to the serverlessdistributed file system 150 for the creation, storage, retrieval,reading, writing, modifying, and verifying of files and directories onbehalf of computing device 150. The control module 220 uses a segmentingmodule 222, a cryptographic engine 224, a hashing module 226, asigning/verification module 228, and tree builder 230 when handling theencrypted files 240 stored in the distributed system portion of the massstorage 208. These components 222-230 perform the various operations ofthe convergent encryption process to create and maintain files, as wellas facilitating verification of the contents of the files withoutdecryption. These components are described in more detail below.

The server component 202 includes a distributed system control module250 and a duplication identifier 252. Distributed system control module250 manages access to the encrypted files 240. It communicates with massstorage device 208 to store and retrieve encrypted files 240.Distributed system control module 250 also maintains a record of theencrypted directory entries (not shown) in memory 206 and/or massstorage device 208 that are stored at computing device 200 (oralternatively that are stored elsewhere in the serverless distributedfile system).

Duplication identifier 252 helps identify identical encrypted files inthe distributed file system. When the duplication identifier 252 finds aduplication that is not an intentional replication for fault tolerantpurposes, the duplication identifier 252 notifies the control module250, which then eliminates the duplicated file and adds the accesscontrol entries to the eliminated file to the remaining file.

FIG. 3 illustrates a more general computer environment 300, which isused to implement the distributed file system. The computer environment300 is only one example of a computing environment and is not intendedto suggest any limitation as to the scope of use or functionality of thecomputer and network architectures. Neither should the computerenvironment 300 be interpreted as having any dependency or requirementrelating to any one or combination of components illustrated in theexemplary computer environment 300.

Computer environment 300 includes a general-purpose computing device inthe form of a computer 302. The components of computer 302 can include,by are not limited to, one or more processors or processing units 304, asystem memory 306, and a system bus 308 that couples various systemcomponents including the processor 304 to the system memory 306.

The system bus 308 represents one or more of any of several types of busstructures, including a memory bus or memory controller, a peripheralbus, an accelerated graphics port, and a processor or local bus usingany of a variety of bus architectures. By way of example, sucharchitectures can include an Industry Standard Architecture (ISA) bus, aMicro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, aVideo Electronics Standards Association (VESA) local bus, and aPeripheral Component Interconnects (PCI) bus also known as a Mezzaninebus.

Computer 302 typically includes a variety of computer readable media.Such media can be any available media that is accessible by computer 302and includes both volatile and non-volatile media, removable andnon-removable media.

The system memory 306 includes computer readable media in the form ofvolatile memory, such as random access memory (RAM) 310, and/ornon-volatile memory, such as read only memory (ROM) 312. A basicinput/output system (BIOS) 314, containing the basic routines that helpto transfer information between elements within computer 302, such asduring start-up, is stored in ROM 312. RAM 310 typically contains dataand/or program modules that are immediately accessible to and/orpresently operated on by the processing unit 304.

Computer 302 may also include other removable/non-removable,volatile/non-volatile computer storage media. By way of example, FIG. 3illustrates a hard disk drive 316 for reading from and writing to anon-removable, non-volatile magnetic media (not shown), a magnetic diskdrive 318 for reading from and writing to a removable, non-volatilemagnetic disk 320 (e.g., a “floppy disk”), and an optical disk drive 322for reading from and/or writing to a removable, non-volatile opticaldisk 324 such as a CD-ROM, DVD-ROM, or other optical media. The harddisk drive 316, magnetic disk drive 318, and optical disk drive 322 areeach connected to the system bus 308 by one or more data mediainterfaces 326. Alternatively, the hard disk drive 316, magnetic diskdrive 318, and optical disk drive 322 can be connected to the system bus308 by one or more interfaces (not shown).

The disk drives and their associated computer-readable media providenon-volatile storage of computer readable instructions, data structures,program modules, and other data for computer 302. Although the exampleillustrates a hard disk 316, a removable magnetic disk 320, and aremovable optical disk 324, it is to be appreciated that other types ofcomputer readable media which can store data that is accessible by acomputer, such as magnetic cassettes or other magnetic storage devices,flash memory cards, CD-ROM, digital versatile disks (DVD) or otheroptical storage, random access memories (RAM), read only memories (ROM),electrically erasable programmable read-only memory (EEPROM), and thelike, can also be utilized to implement the exemplary computing systemand environment.

Any number of program modules can be stored on the hard disk 316,magnetic disk 320, optical disk 324, ROM 312, and/or RAM 310, includingby way of example, an operating system 326, one or more applicationprograms 328, other program modules 330, and program data 332. Each ofsuch operating system 326, one or more application programs 328, otherprogram modules 330, and program data 332 (or some combination thereof)may implement all or part of the resident components that support thedistributed file system.

A user can enter commands and information into computer 302 via inputdevices such as a keyboard 334 and a pointing device 336 (e.g., a“mouse”). Other input devices 338 (not shown specifically) may include amicrophone, joystick, game pad, satellite dish, serial port, scanner,and/or the like. These and other input devices are connected to theprocessing unit 304 via input/output interfaces 340 that are coupled tothe system bus 308, but may be connected by other interface and busstructures, such as a parallel port, game port, or a universal serialbus (USB).

A monitor 342 or other type of display device can also be connected tothe system bus 308 via an interface, such as a video adapter 344. Inaddition to the monitor 342, other output peripheral devices can includecomponents such as speakers (not shown) and a printer 346 which can beconnected to computer 302 via the input/output interfaces 340.

Computer 302 can operate in a networked environment using logicalconnections to one or more remote computers, such as a remote computingdevice 348. By way of example, the remote computing device 348 can be apersonal computer, portable computer, a server, a router, a networkcomputer, a peer device or other common network node, and the like. Theremote computing device 348 is illustrated as a portable computer thatcan include many or all of the elements and features described hereinrelative to computer 302.

Logical connections between computer 302 and the remote computer 348 aredepicted as a local area network (LAN) 350 and a general wide areanetwork (WAN) 352. Such networking environments are commonplace inoffices, enterprise-wide computer networks, intranets, and the Internet.

When implemented in a LAN networking environment, the computer 302 isconnected to a local network 350 via a network interface or adapter 354.When implemented in a WAN networking environment, the computer 302typically includes a modem 356 or other means for establishingcommunications over the wide network 352. The modem 356, which can beinternal or external to computer 302, can be connected to the system bus308 via the input/output interfaces 340 or other appropriate mechanisms.It is to be appreciated that the illustrated network connections areexemplary and that other means of establishing communication link(s)between the computers 302 and 348 can be employed.

In a networked environment, such as that illustrated with computingenvironment 300, program modules depicted relative to the computer 302,or portions thereof, may be stored in a remote memory storage device. Byway of example, remote application programs 358 reside on a memorydevice of remote computer 348. For purposes of illustration, applicationprograms and other executable program components such as the operatingsystem are illustrated herein as discrete blocks, although it isrecognized that such programs and components reside at various times indifferent storage components of the computing device 302, and areexecuted by the data processor(s) of the computer.

An implementation of the distributed file system 150 may be described inthe general context of computer-executable instructions, such as programmodules, executed by one or more computers or other devices. Generally,program modules include routines, programs, objects, components, datastructures, etc. that perform particular tasks or implement particularabstract data types. Typically, the functionality of the program modulesmay be combined or distributed as desired in various embodiments.

An implementation of the file format for the encrypted files may bestored on or transmitted across some form of computer readable media.Computer 19 readable media can be any available media that can beaccessed by a computer. By way of example, and not limitation, computerreadable media may comprise “computer storage media” and “communicationsmedia.”

“Computer storage media” includes volatile and non-volatile, removableand non-removable media implemented in any method or technology forstorage of information such as computer readable instructions, datastructures, program modules, or other data. Computer storage mediaincludes, but is not limited to, RAM, ROM, EEPROM, flash memory or othermemory technology, CD-ROM, digital versatile disks (DVD) or otheroptical storage, magnetic cassettes, magnetic tape, magnetic diskstorage or other magnetic storage devices, or any other medium which canbe used to store the desired information and which can be accessed by acomputer.

“Communication media” typically embodies computer readable instructions,data structures, program modules, or other data in a modulated datasignal, such as carrier wave or other transport mechanism. Communicationmedia also includes any information delivery media. The term “modulateddata signal” means a signal that has one or more of its characteristicsset or changed in such a manner as to encode information in the signal.By way of example, and not limitation, communication media includeswired media such as a wired network or direct-wired connection, andwireless media such as acoustic, RF, infrared, and other wireless media.Combinations of any of the above are also included within the scope ofcomputer readable media.

File Format

FIG. 4 generally shows a file format 400 of a file that is stored in thedistributed file system 150. The file format is composed of two parts: adata stream 402 and a metadata stream 404. The data stream 402 containsthe contents of the file, which makes up the bulk of the entire file.The data stream 402 is a primary (unnamed) data stream that may beanalyzed using the single instance store (SIS) technology introduced byMicrosoft Corporation and discussed in the Background section. SIScomponents work on unnamed streams, while ignoring other streams. Themetadata stream 404 of the file 400 is a separate named stream that isignored by the SIS system.

For discussion purposes, each file is described as containing only asingle user-defined stream, and that stream is the unnamed data stream.However, the distributed file system 150 is capable of supporting anynumber of user-defined streams per file. A file naming conventiondifferentiates among multiple streams by prepending a user-definedstream name to a file system stream name “FSMetadata$”. So, if a userfile has a named stream called “alternateStream”, the file would have asecond metadata stream called “alternateStreamFSMetadata$.” If a userhas the bad taste to name a stream with a string that ends in“FSMetadata$” followed by 0 or more “$”s, the file system changes thename of the stream by adding an additional “$”.

Data Stream 402

The data stream 402 is designed to allow efficient verification,reading, and writing of portions of the file, without affecting otherportions. The data stream is encrypted using the convergent encryptiontechnology described above beneath the heading “File Encryption”. Forsmall files, the entire file is hashed and encrypted using the resultinghash value as the encryption key. The encrypted file can be verifiedwithout knowledge of the key or any need to decrypt the file first.

For large files, however, it is difficult to read or update only part ofa file because the encryption of the file is based on a hash of theentire file contents. Any write to a file would require re-hashing theentire file followed by re-encrypting with the newly generated hash asthe key. Furthermore, verification involves hashing the entire file andexamining the hash value. Taking a single hash of the ciphertext of alarge file for verification purposes makes writes to part of the fileexpensive, because any write would once again require hashing the wholefile.

To overcome this problem for large files, the file contents in the datastream 402 can be broken into smaller blocks and then convergentencryption can be applied separately to each block. FIG. 5 shows a fileF that is segmented by segmenting module 222 into an array 500 ofmultiple blocks 502(0)-502(n−1). In one implementation, the blocks arefixed sized chunks. For example, the file F is segmented into “n” pagesF⁰-F^(n−1), where each page is a fixed size. A 4 Kbyte size is onesuitable size of each block because it is the smallest page size used byNT systems (although some architectures use multiples of 4K). Hence, itis the smallest chunk that the memory manager is going to request on acache miss or user mapped file page fault, and it is also the smallestchunk that is going to be written by the lazy writer.

From the system perspective, each page is originally deemed as“cleartext”, meaning that it has not yet undergone encryption as part ofthe convergent encryption process. The file F may actually be in aplain, unencrypted form, or it may have already been encrypted in somemanner. Thus, by noting that each file page is “cleartext”, we aresimply explaining the process from the point of view of the convergentencryption process, regardless of the condition in which file Foriginally resides.

Convergent encryption is then applied to the file at the block level.That is, each block F^(i) is separately hashed using a one-way hashfunction (e.g., SHA, MD5, etc.) to produce a hash value h(F^(i)). Eachblock F^(i) is then encrypted using a symmetric cipher (e.g., RC4, RC2,etc.) and the hash value h(F^(i)) as the key, or E_(h(Fi))(F^(i)). Thisproduces an array 504 of encrypted blocks 506(0)-506(n−1).

The encrypted blocks 506 form the contents of the unnamed data stream402 in file 400. That is, the data stream 402 contains encrypted blocksE_(h(Fi))(F^(i)) for all i from 0 to the size of the file in pages minusone. Nothing else goes in the main stream.

Metadata Stream 404

Returning to FIG. 4, the metadata stream 404 of the file 400 storesmetadata used to describe the contents of the file and to decrypt thefile. The metadata stream 404 contains a header 406, a tree structure408, and some per user information 410.

Header 406

The header 406 contains information pertaining to the file and which maybe used to validate the file. In FIG. 4, the header 406 is illustratedas including such file information as a file number 412, a revisionnumber 414, a hash value 416 of the root of tree structure 408, and anoptional digital signature 418.

Exemplary implementations of the header will be described according tothree different file formats, each of which possess differentadvantages. The three formats include a signed format, an unsignedformat, and a delegation format. The signed format contains a digitalsignature 418 associated with the file and information used to verifythe signature. The unsigned file format omits the digital signature andverification information. The delegation format accepts delegationcertificates to convey ownership or privileges with respect to the file.The signed and unsigned formats are described immediately below, whilethe delegation format is described further along in this discussionbeneath the heading “File Format Using Delegation Certificates”.

With the unsigned format, the directory servers send a hash value thatrepresents the contents of the file (as well as its metadata) to averifying machine for verification of the file contents. In thisimplementation, there is no way for the verifying machine to determinethat a particular user wrote a file, aside from trusting the directoryservers. The advantage of this approach is that there is no need tocompute or verify digital signatures for the file, which can becomputationally expensive. The disadvantage is that the verifyingmachine must trust the directory servers, although this is less of aproblem than it might seem on its face. Even with the signed format,where it is possible to verify that a particular user wrote a filewithout trusting the directory servers, one still relies on thedirectory servers to verify that the correct version of the file ispresent (as opposed to a different file or a old version of the correctfile), and to state which user(s) are allowed to sign a particular file.In practice, corrupt directory servers could do much damage even withsigned files, so electing to use unsigned files and dropping thesignatures saves computational cost at a slight increased risk ofreliance on the directory servers.

The following example header contains fields common to all threeformats. Fields marked with (SF) exist only in the signed format thatuses signatures.   ULONG MagicNumber; (must be 0x0fa2317e)   UCHARFormatVersionMajor; (1 described here)   UCHAR FormatVersionMinor; (1described here)   USHORT Flags; 1 means alternate signature type 2 meansshort header format   GUID FileId;   FILE_USER_NAME FileOwner;   TimeFileCreateTime; E.g., 64 bit NT time   Time FileModifyTime;   LONGLONGFileRevisionNumber; (SF)   FILE_USER_NAME LastWriter;   LONGLONGFileSize;   LONGLONG FragmentOffset;   LONGLONG FragmentSize;   ULONGUserKeyCount; The number of KEY_ID_PAIRS   ULONG FilePageSize;   ULONGBytesPerTreeBlock;   USHORT PublicKeyAlgorithm; 1 is RSA, othersundefined   USHORT HashAlgorithm; 1 is SHA, 2 is MD5   USHORTSymmetricAlgorithm; 1 is RC4, 2 is RC2   USHORT SymmetricKeySize;  USHORT SignatureSize; (SF)   LONGLONG KeyPairOffset; File offset ofthe KEY_ID_PAIRs   LONGLONG KeyDataOffset;   LONGLONG SignatureOffset;(SF) The file offset of the sig @ SignatureOffset: (SF)   <SignatureList, signed by the LastWriter, size SignatureSize> @ KeyPairOffset:  KEY_ID_PAIR UserKeys[UserKeyCount]; @ KeyDataOffset:   The key data,as described below.

The MagicNumber field characterizes the type of header. TwoFormatVersion fields describe the format version of the encrypted fileitself and are intended to be used to allow an on-disk format to evolveover time. If the distributed file system 150 encounters a newerFormatVersionMajor than it presently understands, the file system isunable to understand the file. The file system ignoresFormatVersionMinors that are too big and treats the format as if it werethe newest understood by the file system and consistent with theFormatVersionMajor.

The Flags field contains a first flag to differentiate between whetherthe signed format or the delegation format is employed. The Flag fieldalso contains a second flag to differentiate between a short header formand a long header form. If the second flag is set to indicate a shortheader form, the rest of the header after the FileModifyTime field usesthe following format rather than the one presented above: USHORTFileRevisionNumber; (SF) USHORT FileSize; USHORT SignatureSize; (SF)<Signature List, signed by the FileOwner, size SignatureSize> (SF) <Asingle KEY_ID_PAIR goes here>

The short header form is intended for small files (typically 4K or less,although they can be as big as 64K). The conditions in which the shortheader form can be used are:

-   -   The LastWriter and FileOwner are the same;    -   There is only one key-id pair entry;    -   The file uses RSA/SHA and constant size (e.g., 128-bit)        symmetric keys;    -   The revision number fits in a USHORT in the signed format case;        and    -   Employs a single file encryption/cleartext hash (as is done with        files that are less than or equal to one file page size in the        normal format).

The short header form is intended for the extremely common case of verysmall files that are created once and rarely (or never) overwritten, andreadable by either everyone or just the creator. This may be as many ashalf of all files. The short header form is incompatible with thedelegation format, but since these files are created in one piece andthen left alone and the delegation format is intended to addressin-place updates, the incompatibility is not a problem. The distributedfile system is free to decide whether to use the short or long headerform for any particular file, and can switch formats on the file(assuming that it has access to the writing user's key).

The FileId field contains the file number in the form of a globallyunique ID. The FileOwner field identifies the file owner, theFileCreateTime field specifies the time of file creation, and theFileModifyTime field specifies the last time the file was modified. TheFileRevisionNumber field, which is only present in the signed format, isupdated every time a file is written, closed, and signed (i.e., not forevery write to the file). The directory servers will know what thelatest revision of a file is.

The LastWriter field notes the last user to write to the file. This useris also the one who issued the signature for the file contents stored atthe offset held in the SignatureOffset field. The type FILE_USER_NAMEthat is used for the LastWriter and FileOwner fields supports twoglobally unique identifiers, one for the user and one for an authoritythat certifies the identity of the user, although there are a number ofother possibilities for user names, including a hash of the user'spublic key. The FileSize field describes the size of the entire file,while the FilePageSize field specifies the size of each page in thefile.

The FragmentOffset and FragmentSize fields are intended to support verylarge files that have been broken into fragments to make them moremanageable by the replica placement and regeneration systems. As oneexample default, the FragmentOffset field is set to zero and theFragmentSize field equals FileSize.

The PublicKeyAlgorithm field specifies a suitable public key cipher,such as RSA. The HashAlgorithm field identifies a suitable hashalgorithm, such as SHA or MD5. The SymmetricAlgorithm field specifies asuitable symmetric cipher, such as RC2 or RC4, and it employs keys of asize specified in the SymmetricKeySize field (e.g., 128 bit).

The KeyPairOffset field contains an offset value to a location in themetadata stream that holds the key ID pairs (per user information 410).The KeyDataOffset field contains an offset value to a location in themetadata stream where the tree 408 is located.

Tree Structure 408

The tree 408 is the portion of the metadata stream 404 that facilitatesindexing into individual blocks in the data stream 402, thereby enablingdata verification of the contents in the data stream. The tree containsdata for two purposes: (1) allow a user to decrypt the file one block ata time and out of order, and (2) allow data servers to verify that thecontents of the file is genuine one block at a time and out of order andwithout having access to the keys of any of the authorized readers ofthe file. In this manner, the tree 408 allows the distributed filesystem 150 to verify individual encrypted blocks 506 directly, withoutdecryption and without any knowledge of the encryption keys used toencrypt the file.

FIG. 6 shows a tree structure 408 in more detail. There are two types ofentries in tree 408: leaf entries and higher-order entries. They differin that the decryption keys are held only in the leaf entries, whileboth the leaf entries and the higher-order entries contain hashes thatare used to determine whether the file contents are correct.

In FIG. 6, the tree 408 defines leaf nodes 602(0)-602(n−1) for each ofthe corresponding encrypted blocks 506(0)-506(n−1). Each leaf node L^(i)contains two components: (1) an access value 604 used for decrypting thecorresponding block and (2) a verification value 606 used for verifyingthe corresponding block. In the illustrated implementation, the accessvalue 604 is formed by encrypting a hash of the cleartext file blockusing a symmetric cipher E and a randomly generated key K, orAccess Value=E _(K)(h(F ^(i))).The symmetric cipher specified in the SymmetricAlgorithm field of theheader is used for this encryption (e.g., RC2 or RC4).

The verification value 606 is created by hashing the associatedencrypted block, or:Verification value=h(E _(h(Fi))(F ^(i))).

A leaf entry possesses the following format: BYTEEncrypyedCleartextHash[HASH_SIZE]; BYTEUnencryptedCiphertextHash[HASH_SIZE];where EncryptedCleartextHash is the access value 604 and theUnencryptedCiphertextHash is the verification value 606. The HASH_SIZEvalue depends on the HashAlgorithm specified in the header 406. For theSHA algorithm, it is 20 bytes and for the MD5 algorithm, it is 16 bytes.When RC2 encryption is used for the EncryptedCleartextHash, the size is24 bytes due to padding, regardless of which hash algorithm (MD5 or SHA)is used.

The existence and size of the tree 408 varies with the size of the file.At one extreme, if the file is less than or equal to one page in size,there is no tree and no per-file secret key K. Instead, the cleartexthash value is turned into a key, encrypted with the public keys of thereaders, and stored in the FILE_KEY_ID_PAIR. The hash of the file (thatis stored at the directory servers or signed and placed in the file)includes the entire contents of the ciphertext of the file in place ofthe hash of the highest level that exists in the tree. Since about halfof all files are smaller than 4K, this optimization can be significant.

For slightly larger files, the tree may be one level deep, containingonly the leaf nodes 602 and one root node formed from the leaf nodes. Asa general rule, if the count of pages in a file is greater than one butless than a moderate value obtained by dividing the BytesPerTreeBlock bythe leaf entry size (i.e., approximately 3.2 Mbytes for SHA, 4K filepages and BytesPerTreeBlock of 32 Kbytes), the tree 408 only containsleaf nodes and no higher order entries. The number of leaf nodes 602 issufficient to contain enough entries to describe all of the pages in thefile. For the signed format case, the LastWriter signs the header, theper user information, and one or more verification values from the tree,as described in more detail below. In the unsigned format case, thedirectory servers store the hash that the LastWriter would have signed.

For large files, the cost of computing the hashes can be quite high. Forexample, for a 500 Mbyte file (e.g., an email file) and 4K file pages,there are approximately 128,000 hashes. At twenty bytes per hash, asingle block update to this file would require 2.5 MB of hashing.

To reduce the amount of work for small writes to large files, the treemay be configured with one or more intermediate levels of hashes. InFIG. 6, the leaf nodes 602 are grouped into tree blocks (e.g., denotedas TB₀ ⁰ to mean tree block 0 at tree level 0). The size of a block isspecified in the BytesPerTreeBlock field in header 406. If the blocksize does not divide evenly by the size of a leaf (or higher order)entry, the block is padded with zeroes after the last complete entry.

The tree block is hashed using a one-way hashing function to formintermediate nodes 610(0)-610(j). A higher order intermediate node hasthe following format: BYTE HashOfLowerOrderEntry[Hash_SIZE];

Each hash is of an entire block of the next lower level of the tree,excluding any trailing padding and excluding the unused portion of thefinal leaf block. The first higher order block follows the firstcomplete leaf tree block. Unlike the leaf tree blocks, the higher orderblocks are allocated as a whole because if there is a higher orderblock, there is also a leaf tree block following it. By allocating thewhole block, the system avoids having to move the whole structure aroundto expand the file. Using the example parameters from above, a firsthigher order block is not used until the file is approximately 3.2 MB.Thus, the maximum wasted space for a higher order block is 1% (32 Kb/3.2MB), which is on the order of the cost of the leaf tree entries.

The array of intermediate nodes 610 can again be grouped into blocks(e.g., denoted as TB₁ ⁰ to mean tree block 0 at tree level 1) and eachblock is hashed to form the next level of nodes represented by node620(0). The grouping and hashing process can be repeated as many timesas desired until reaching a tree root, which is denoted as R_(x) ⁰.After the first higher order block follows more leaf tree blocks untilall of the entries in the higher order block are filled, at which timefollows another leaf block and the next higher order block, followed bythe rest of the leaf blocks for the second higher order block, the firstleaf block for the third higher order block, the third higher orderblock, and so on. It is noted, however, that the second higher orderblock is rarely used since it typically is introduced for very largefiles of approximately 5.2 GB or greater (using the example parameters).

The layout has the following recursive definition, in which thesuperscripts are eliminated for clarity:C₀=LC _(x) =C _(x−1) H _(x) C _(x−1) C _(x−1) , . . . C _(x−1)where H_(x) indicates an x^(th)-order higher-level block. So, the layoutof the data in a two-level tree is as follows:L⁰H₁ ⁰L¹L² . . . L^(n−1)H₂ ⁰L^(n)H₁ ¹L^(n+1) . . . L^(2n−1)L^(2n)H₁²L^(2n+1) . . .where n is the number of entries in the higher order block.

The tree root is then hashed to form the root node 630, or h(R_(x) ⁰).This hash value may then be hashed together with the metadata header 406and per user information 410 and the resulting hash stored at thedirectory servers in the case of the unsigned format, or signed using auser's signature in the signed format case. In this way, the hash orsignature covers the higher order blocks (of the highest order thatexists in the file) and thereby indirectly covers the leaf blocks. Thesignature covers the used entries in the higher order blocks, not theunused entries and padding. Similarly, the hash entry in the higherorder block of the final leaf block does not include any unusedentries/padding in that leaf block.

With this tree structure, every small update to the file merely involveschanging the file block, the leaf node associated with the file block,and the nodes in the tree branch to the leaf node. This solution reducesthe hashing cost because the number of upper-level hashes that need tobe modified for any given write grows logarithmically in the size of thefile. Therefore, with the hash tree, any work to update a particularbyte of the file is proportional to the depth of the tree, which growswith the log of the size of the file.

It is noted that although a multi-level tree index is described hereinas one possible implementation, other forms of indexing structures maybe used.

User Key List

To grant access privileges to multiple users, the file system 150maintains a user key list for each file. Each entry in the user key listcontains the data used by specific users to decrypt the file. Moreparticularly, the randomly generated key K, which is used to encrypt thehash of the blocks of the cleartext file F (i.e., forming the accessvalue 604), is encrypted using each authorized user's public key andstored in a user key list, or E_(UiPubKey)(K).

FIG. 7 illustrates a user key list 700 for the file F. Each entry inlist 700 includes a user name 702 of the user with access privileges andthe encrypted symmetric key 704. If the file is publicly readable, thekey list 700 contains only a special entry 706, in which theFILE_USER_NAME is the reserved value USER_EVERYONE to indicate thateveryone has access, and the associated encrypted key segment containsthe key data in the clear.

Each entry in the key list 700 has the following format:FARSITE_USER_NAME UserName; ULONG EncryptedKeyBlobSize; BYTEEncryptedKeyBlob[EncryptedKeyBlobSize];

-   -   The content of the EncryptedKeyBlob field depends on the size of        the file. If the file is one page or less in size, the field        contains the key derived from the hash of the cleartext of the        file, encrypted with the public key of UserName. If the file is        bigger than one page, the field contains the random symmetric        key K that was used to encrypt the hashes of the cleartext of        the file in the leaf tree block(s), also encrypted with the        public key of UserName.

There are two different types of signatures for a file, depending on howthe file is written. In the signed format, the file is signed by theuser who is named in the LastWriter field. The signature covers the fileheader (up to and including the SignatureSize), but does not cover thethree offsets so that servers can re-arrange pieces of the Metadata$stream as they see fit, without having the last writer's key. After theheader, the signature then covers the key-id pairs. Following that, itcovers either the file ciphertext, the single leaf tree block, or thehighest order tree block, depending on the file's size. In the signedformat, all that is stored at SignatureOffset is the actual signatureblob.

For small files, the user key list 700 does not contain entries withencrypted symmetric keys. Instead, each entry contains a user name(i.e., FILE_USER_NAME 702) and an encrypted version of the hash of theentire file (i.e., h(F)), which is encrypted using the user's publickey. Accordingly, this portion of the entry would resembleE_(UiPubKey)(h(F)).

Since files are stored on machines that are not trusted, read accesscannot be sufficiently controlled merely by listing the authorizedreaders of a file in the metadata, as is commonly done in trusted filesystems. Thus, this file format relies on cryptography to provide accesssecurity. Only a truly authorized user with knowledge of an appropriateprivate key will be able to recover the access key K. As a result, animpostor who attempts to recover the key K using an authorized user'sname will be unable to decrypt the access key K because that impostordoes not have knowledge of the user's private key.

An alternative technique may be used in the case where the user creatingthe file (i.e., the user who makes up K) is the same as the user in theuser key list 702. In this case, a secret symmetric key that is knownonly by that user can be used in place of that user's public keyU_(iPubKey). Since symmetric key operations are substantially cheaperthan public key operations in terms of computational resources, creatingand reading the file would be computationally cheaper in the common casethat the file creator is the same as the file reader.

File Format Using Delegation Certificates

The third type of file format (in addition to the signed and unsignedformats) is one in which delegation certificates are used in place ofdigital signatures. Setting the first flag in the Flags field of theheader 406 signifies the delegation format. The delegation format isused to handle a case where a machine crashed while in the process ofwriting a file, before the last writer signed that file. With thisformat, a user's machine may create a delegation certificate allowingother entities to verify as a group the authenticity of the file onbehalf of the user in the event the user's machine is unavailable tomake the verification.

When a computing device attempts to write a file to the distributed filesystem 150 and receives a write lock for a file or directory, thecomputing device generates a random symmetric key, known as the“lock-secret” key. The computing device uses secret sharing to break thelock-secret key into multiple pieces, one piece for each of thedirectory servers, with a specified number of the servers beingsufficient to recover the key.

If the computing device wants to commit updates to a file withoutattaching a full signature to the file (such as on a write-through writeto a database file), the computing device generates a delegationcertificate and signs the certificate with the user's private key. Whenthe computing device updates a file, it computes the hash of the filethat would normally be signed with the writer's private key. However,instead of signing the update, the computing device encrypts it with thelock-secret key using the symmetric signature algorithm specified in thefile header.

If a machine crashes with file updates that are signed with thesymmetric signature key (rather than with the normal private-keysignature), there will be a set of files signed by lock-secret keys onrecovery. For each particular lock-secret key, the computing devicetakes all files signed by that key and sends the delegation certificatesand “symmetric key signatures” to all available directory servers. Oncethe directory servers have collected all of the appropriate data, theybreak the seal on the lock-secret key and determine whether the hash ofthe lock-secret key matches the hash in the DelegationCertificate field.The directory server then decrypt the symmetric key signature (i.e.,decrypt the file hash with the lock-secret key) and fill out and sign aDelegationCountersign using the decrypted file hash.

In the delegation format, the following structure is stored at theSignatureOffset field of the header:   LONGLONGDelegationCertificateOffset;   LONGLONG DirectoryServerSignaturesOffset;@ DelegationCertificateOffset is:   ULONG Magic; (must be 0xde11ca7e)  UCHAR FormatVersionMajor; (1 described here)   UCHARFormatVersionMinor; (1 described here)   USHORT HashedKeySize;   TimeDelegationTime;   GUID FileId;   GUID DelegationCertificateId;  LONGLONG FileVersionNumber;   FILE_USER_NAME LastWriterName;   ULONGDirectoryServerCount;   ULONG NumDirectoryCOuntersignsNeededForValidity;  FILE_MACHINE_NAME DirectoryServer[DirectoryServerCount];   ULONGSignatureSize;   <a hash of the secret “signature” symmetric key, ofHashedKeySize, using   the hash algorithm specified in the file header>  <the signature blob of the LastWriter > @DirectoryServerSignatureOffset is:   ULONGCountOfSigningDirectoryServers;   for each signing server there is aDelegationCountersign:     ULONG Magic (must be 0xc2a38452)     UCHARFormatVersionMajor; (1 described here)     UCHAR FormatVersionMinor; (1described here)     USHORT HashSize;     FARSITE_MACHINE_NAME  SigningMachine;     GUID FileId;     GUID DelegationCertificateId;    LONGLONG FileVersionNumber;     Time CountersignTime;     ULONGSignatureSize;     <A hash for the file contents, computed just as thehash that the     last writer would sign in the normal signature method,of     HashSize>     <A signature of the directory server certificate upto but not     including SignatureSize, followed by the file contentshash>

The signature in the delegation certificate covers everything from theMagic field up to but not including the SignatureSize field, and thenthe hash of the secret symmetric signature key. The signature of thedirectory servers is over what would have been signed by the useridentified in the LastWriter field in the signed format case. Note thatthere is a separate SignatureSize for each of the directory servers,since they may have different key lengths and so different signaturelengths.

To validate a file using the delegation format, the verifying computerfirst evaluates the signature on the delegation certificate and confirmsthat the certificate has the correct FileId and FileVersionNumber. Itthen counts the number of valid DelegationCountersign's, and if thatnumber is at least NumDirectoryCountersignsNeededForValididty then thefile is valid.

To check a DelegationCountersign, the verifying computer verifies thatSigningMachine is on the list in the DelegationCertificate, that theFileId, FileVersionNumber and DelegationCertificateId match theDelegationCertificate, and that the hash value is the same as the hashvalue that would have been signed by the last file writer in the normalsigned file format.

There is a related technique for the non-signature case. As before, whena computing device attempts to write a file to the distributed filesystem 150 and receives a write lock for a file or directory, thecomputing device generates a symmetric encryption key called the“lock-secret key.” The computing device breaks the lock-secret key intomultiple pieces and distributes the pieces to the directory serversusing a cryptographic secret sharing technique.

If the computing device subsequently wants to commit updates to a filewithout attaching a signature, the computing device encrypts the updateswith the lock-secret key using the symmetric encryption algorithmspecified in the file header. If the directory servers are satisfiedwith the result, the servers accept the file contents as being valid andupdate their internal data structures. In this case, the process ofproducing a delegation certificate and countersigning certificate areeliminated.

File Construction

FIG. 8 shows a process 800 for constructing a file according to theformat shown in FIGS. 4-7 for storage in the distributed file system150. The process can be implemented in software as computer executableinstructions that, when executed, perform the operations depicted inblocks. The process 800 will be described with reference to componentsin the computing device 200 shown in FIG. 2 as exemplary mechanisms forperforming the operations, and with reference to the file formatillustrated in FIGS. 4-6.

The file construction process 800 builds files differently dependingupon their size. Accordingly, at operation 802, a preliminary inquiry isto ascertain the size of the file. If it is a small file (e.g., 4K orless), the storage/retrieval control module 220 of the client component204 encrypts the entire file using convergent encryption techniques(operation 804).

Alternatively, assuming the file is not small (i.e., the “no” branchfrom operation 802), the control module 220 proceeds to a technique forconstructing a large file for storage in the distributed file system.Large file construction can be conceptualized as two phases: a firstphase for creating the data stream 402 and a second phase for creatingthe metadata stream 404.

In the first phase, the control module 220 employs the segmenter 222 todivide a file F into “n” multiple blocks 502(0)-502(n−1) at operation806. Each block contains a portion of the file, which is illustrated asfile segments F⁰, F¹, F², . . . , F^(n−1) in blocks 502. At operation808, the control module 220 invokes the hash module 226 to hash eachblock 502(0)-502(n−1) to produce intermediate hash values h(F^(i)). Atoperation 810, the control module 220 calls the cryptographic engine 224to encrypt each block 502(0)-502(n−1) using that block's hash value, orE_(h(Fi))(F^(i)). In practice, the hashing and encrypting operations maybe accomplished sequentially for each block, one block at a time, beforeproceeding to the next block. For instance, for each block, a loop maybe used to compute the hash of the block, encrypt the result, and thenproceed to the next block. With this approach, the two accesses to theblock are close together in time, which increases the likelihood thatthe data for the block will be found in the cache and so be faster toperform. The segmented and encrypted file can then be stored as theunnamed data stream 402.

During the second phase, the control module 220 uses the tree buildermodule 230 to construct the block-level access tree. At operation 812,the tree builder 230 (or other module in the client component) generatesa random K for the entire file. The tree builder 230 then creates a leafnode L^(i) for each block 502(0)-502(n−1) (operation 814). Each leafnode L^(i) contains two components: (1) an access value 604 used fordecrypting the corresponding block and (2) a verification value 606 usedfor verifying the corresponding block. Accordingly, operation 814 can beviewed as two parts. At the first part represented by operation 814(A),the tree builder 230 computes the access value by encrypting the filesegment hash h(F^(i)) using the key K, or E_(K)(h(F^(i))). At the secondpart represented by operation 814(B), the tree builder 230 computes theverification value by hashing the corresponding encrypted file segment,or h(E_(h(Fi))(F^(i))).

At operation 816, the tree builder 230 ascertains whether the treestructure would benefit from an intermediate level of nodes in terms ofaccess and verification efficiency. The number of levels in the treegenerally depends on the size of the file and the desired fan-out. For asmaller file (e.g., a file that is greater than 4 KB but less than 3.2MB), the tree is one level deep, containing only the leaf nodes. For alarger file (e.g., one that is greater than 3.2 MB), another level ofnodes is added to enable more efficient access of the leaf nodes.

If another level of nodes is desired (i.e., the “yes” branch fromoperation 816), the tree builder 230 groups sets of contiguous leafnodes to form tree blocks TB_(m) ^(n) (operation 818). Then, atoperation 820, each tree block is hashed to form intermediate tree nodes610(0)-610(j). The process continues at operation 816, where the treebuilder 230 again determines whether a further level of intermediatenodes would prove useful. If the file is very large (e.g., greater than5.2 GB), the tree might include a second level of intermediate nodes. Inthis case, operations 818 and 820 are repeated such that theintermediate nodes in the first level are grouped together to constructa second level of tree blocks (block 818) and each tree block is hashed(block 820). Depending on the file size, this process is repeated asmany times as needed until the highest-level node contains only oneblock.

Once an effective node structure is created and no more intermediatenodes are desired (i.e., the “no” branch from operation 816), the treebuilder 230 forms the root R_(x) ⁰ and hashes it to form a hash valueh(R_(x) ⁰) (operation 822). In the case of the signed format, thecontrol module 220 invokes the signing/verification module 228 to signthe file header 406, per-user information 410 and root node h(R_(x) ⁰)with the digital signature of the user identified in the LastWriterfield (operation 824). The resultant tree structure 408 is stored in themetadata stream 404. The signature is stored in the header 406 of themetadata stream 404.

File Verification

FIG. 9 shows a process 900 for verifying portions of a large file in itssegmented and encrypted form, without requiring knowledge of the userprivate keys or random keys. For discussion of this process, it isassumed that the file is of sufficient size to have a tree structure 408stored in the metadata stream 404. The process 900 can be implemented insoftware as computer executable instructions that, when executed,perform the operations depicted in blocks. The process 900 will bedescribed with reference to components in the computing device 200 shownin FIG. 2 as exemplary mechanisms for performing the operations, andwith reference to the file format illustrated in FIGS. 4-6.

For discussion purposes, suppose that computing device 200 is averifying machine that is tasked with verifying the first encrypted fileblock 506(0) for file segment F⁰. At operation 902, thesigning/verification module 228 evaluates the signature (if any) on theheader 406, per-user information 410 and tree root of the tree structure408 using the public key of the last writer as indicated in the header406. The signature is held in the header 406 of the metadata stream 404.If the signature is not valid (i.e., the “no” branch from operation904), the file block is deemed not to be authentic (i.e., block 906). Inthe non-signed embodiment, the signing/verification module 228 computesthe hash that would have been signed in the signed format case, andcompares that against the has provided from the directory servers. Ifthe hash does not match, then it follows the “no” branch from operation904.

Conversely, if the signature is valid (i.e., the “yes” branch fromoperation 904), the verification module 228 verifies whether the hashvalue stored at the root matches the hash of the lower-order nodes belowthe root in the tree (i.e., operation 908). If the values do not match,the file block is not authentic (i.e., operation 906). If the hash isverified (i.e., the “yes” branch from operation 908), the verificationmodule 228 traverses the tree, node by node, from the root to the leafnode L⁰ associated with the target block 506(0). At operation 910, theverification module 228 moves to the next node on the path between theroot and the leaf node. If the next node is not a leaf node (i.e., the“no” branch from operation 912), the verification module 228 verifieswhether the hash value stored at the next node matches the hash of thelower-order nodes below that node in the tree (i.e., operation 908). Inthis manner, each node in the path from the root to the leaf node areevaluated. If any one of these verifications fails, the block is notauthentic.

Once the leaf node is reached (i.e., the “yes” branch from block 912),at operation 916, the verification module 228 calls the hash module 226to compute a hash of the encrypted file segment in target block, orh(E_(h(F0))(F⁰)). The verification module 228 then compares thisresultant hash value with the verification value 606 stored in thecorresponding leaf node L⁰ (i.e., operation 918). If the two match(i.e., the “yes” branch from operation 920), the target block 506(0) isauthentic (operation 922). If the two fail to match (i.e., the “no”branch from operation 920), the target block 506(0) is not authentic(operation 906).

Reading a File

FIG. 10 shows a process 1000 for reading one of the file blocks of alarge file without having to read the entire file. As before, it isassumed that the file includes a tree structure 408 and that the targetblock is a block F^(i). The process 1000 can be implemented in softwareand will be described with reference to components in the computingdevice 200 in FIG. 2 and the file format in FIGS. 4-7.

At operation 1002, the storage/retrieval control module 220 obtains therandom access key K from the user key list 700 by indexing into the listusing the File_User_Name 702 of the user who wants to read the targetfile block. The control module 220 extracts the encrypted symmetric key704 and decrypts the access key K using the public key cipher (e.g.,RSA) and the user's private key. It is noted that if the user is notidentified in the user key list 700, the user does not have accessprivileges to read the file and will be prevented from doing so.Additionally, an impostor attempting to recover the key K using theuser's name will be unable to decrypt the access key K because thatimpostor does not have knowledge of the user's private key.

At operation 1004, the control module indexes into the first level ofthe tree structure 408 in the metadata stream 404 to the leaf node L^(i)associated with the target file block F^(i). At operation 1006, thecontrol module 220 removes the access value 604 (i.e., E_(K)(h(F^(i))))and calls the cryptographic engine 224 to decrypt the access value usingthe symmetric cipher D and the symmetric access key K to recover a hashof the target block, as follows:D _(K)(E _(K)(h(F ^(i))))=h(F ^(i)).

At operation 1008, the control module 220 calls again on thecryptographic engine 224 to decrypt the target file block using asymmetric cipher D and the recovered hash value as the key, as follows:D _(h(Fi))(E _(h(Fi))(F ^(i)))=F ^(i).

The file block F^(i) is now in an unencrypted format and ready to beread by the authorized user (i.e., operation 1010).

Writing a File

FIG. 11 shows a process 1100 for writing to or modifying one of the fileblocks of a large file without affecting other blocks of the datastream. Once again, it is assumed that the file is of sufficient size tohave a tree structure 408 stored in the metadata stream 404 and that thetarget block is a block F^(i). The process 1100 can be implemented insoftware and will be described with reference to components in thecomputing device 200 in FIG. 2 and the file format in FIGS. 4-6.

At operation 1102, the computing device modifies a portion of the filecontained in block F^(i), to create a file block F^(i)′. Modifying thedata renders the previously computed hash value inaccurate and henceunusable. Accordingly, at operation 1104, the control module 220 callsthe hash module 226 to compute a new hash value of the modified block,or h(F^(i)′). At operation 1106, the control module 220 calls thecryptographic engine 224 to encrypt the modified file block F^(i)′ usingthe new hash value, or E_(h(Fi′))(F^(i)′). The new encrypted blockreplaces the pre-modified encrypted block in the data stream 402.

These changes to the file block also affect a portion of the treestructure 408 stored in the metadata stream 404. At operation 1108, thetree builder 230 recreates a new leaf node L^(i)′ that is associatedwith the modified block. The tree builder also recreates anyintermediate nodes that reference the new leaf node (either directly orindirectly) as well as the root node (i.e., operation 1110). Atoperation 1112, the tree builder optionally re-signs the header 406,per-user information 410 and root using the last writer's signature, orusing the lock-secret key technique described above

Signed Manifest of File Modifications

In the signed form of the file format, a digital signature is applied tothe header 406, per-user information 410 and root node after everymodification to the file. This is illustrated, for example, as operation1112 in the file write process 1100 of FIG. 11. The advantage of theunsigned file format over the signed file format is that the writer of afile does not need to compute a digital signature when closing the fileafter writing to it. Since digital signatures are computationallyexpensive, this can be a significant savings if file writes areperformed frequently. When using the unsigned file format, instead ofsigning the file, the writer merely sends the file's hash value to thedirectory servers that implement the directory in which the file isstored. When another machine wishes to verify the contents of a file, itcannot check a signature in the file, since there is no signature in thefile to check. The verifying machine thus needs to obtain verificationinformation from some source that is external to the file.

One such source is the directory servers that implement the directory inwhich the file is stored. Since the directory servers store a copy ofthe file's hash value, they can provide this value to the verifyingmachine, and the verifying machine can compare this stored hash value tothe computed hash value of the file. The disadvantage of this approachis that it requires contacting and trusting the directory servers. Thetrust issue is not particularly important, since the directory serversalready have to be trusted with version information and writerauthorizations. However, contacting the directory servers for every fileverification can place a significant additional load on these machines,so it is beneficial to avoid this contact if possible.

Therefore, the present invention includes a mechanism by which thewriter of a file can provide file authentication information to averifying machine without having to compute a new digital signatureevery time a written file is closed. Periodically, the writer compiles alist of the hash values of all files that have been written over arecent interval, computes a hash of the list, and signs the hash. Thissigned list of hash values is known as a manifest, analogous to ashipping manifest that enumerates the items in a shipment. The advantageof using a signed manifest is that the writer need only perform a singlesignature computation in order to authenticate the writes to multiplefiles, rather than having to compute a separate signature for each file,as it would for the signed file format.

The writing machine can then send the signed manifest, along with one ormore of the files that have been written, to a machine that wants a copyof the files. The receiving machine can verify that the signature of thehash of the manifest is valid, that the hash of manifest is valid, andthat the file hash in the manifest corresponds to the hash of the filethat it is interested in. The verifying machine needs to know the listof authorized writers to the file, which it must obtain from thedirectory servers, but this list is generally not modified as frequentlyas the contents of the file, so the load on the directory servers frompropagating updates to the authorized writer list is significantly lowerthan the load from providing a hash value for every new version of afile.

FIG. 12 shows a process 1200 for producing a signed manifest ofmodifications, and FIG. 13 illustrates an exemplary signed manifest. Theprocess 1200 can be implemented in software and will be described withreference to components in the computing device 200 in FIG. 2 and theexemplary signed manifest in FIG. 13.

At operation 1202, the computing device modifies one or more files. Thisstep is typically performed separately for each file, and depending uponthe file size and the scope of the modifications, the control module 220may invoke one or more of the segmenter 222, the crypto engine 224, thehash module 226, and the tree builder 230 in order to update the filemetadata. At operation 1204, the control module 220 calls the hashmodule 226 to compute a new hash value of each modified file. This stepis typically performed separately for each file and in conjunction withthe writing of the new data to the file. The control module 220 collectsthe hash values of every modified file in a manifest (i.e., operation1206).

FIG. 13 shows an exemplary manifest 1300. It includes a collection ofentries 1302-1306 of modified files. Each entry contains both a filenumber (i.e., the file number 412 in the file header 406) and the hashof file. The file number specifies to which file a particular hashapplies. Also, the manifest 1300 includes a magic number header 1308 atthe beginning that helps ascertain what is being signed. This is adifferent magic number than the one found at the beginning of the fileheader.

After collecting a set of changes, the control module 220 invokes thehash module 226 to compute a hash of the contents of the manifest (i.e.,operation 1208), and then it invokes the signing/verifying module 228 tosign the hash of the manifest using the last writer's private key (i.e.,operation 1210). This is represented as the signature 1310 in FIG. 13,which covers the entire manifest. By signing the manifest, the filesystem can verify the user who modified the files in the manner outlinedin the manifest. The timing as to when a manifest is created variesdepending upon implementation requirements.

The manifest may be subsequently verified by initially verifying thesignature 1310. If the signature is valid, the file hash contained inthe manifest is compared to the hash of the file. If the two match, theverifier will then examine the revision number in the file. Action isonly taken if the revision number in the file is bigger than the biggestrevision number that the verifier has ever seen for that file. With thislast evaluation, the verifier prevents malicious/malfunctioning machinesfrom pushing stale versions of files to replica sites.

Sparse Files

A sparse file is a file whose logical size is greater than its physicalsize, potentially possessing large ranges with no data whatsoever. Suchranges are said to be “unallocated” as distinguished from “allocated”ranges that contain actual data. Logically, unallocated regions of afile contain zero data, but there is no physical storage associated withthese regions. Sparse files are used in many different environments(e.g., database logging) and are known in the art. The file formatdescribed above can be used to support sparse files; however, it mayconsume an inefficiently large amount of storage space. This sectiondescribes modifications to the file format that greatly reduce thisinefficiency. No fields are added, removed, or rearranged. However, forefficient handling of sparse files, a few changes can be made to the wayvalues in certain fields are calculated.

If one were to store a sparse file using the file format 400 illustratedin FIG. 4, the allocated size of the metadata stream 404 will beproportional to the total size of the primary data stream 402 thatincludes vast ranges with no content (i.e., the logical file size),rather than proportional to the allocated size of the primary datastream that includes only the content portions of the sparse file (i.e.,the physical file size). One significant case of sparse file usage isfor circular logging using truncate-from-tail. With the file format 400,the metadata 404 would grow linearly as the log is written, but it couldnot be truncated as the log is truncated. Therefore, a file that isexpected to be constant in size would actually grow linearly withoutbound.

The modifications described below adapt the file format so that (1)unallocated primary-stream plaintext is represented by unallocatedprimary-stream ciphertext, and (2) unallocated primary-stream dataproduces corresponding metadata of all zeroes, thereby enabling use ofsparse file allocation for the metadata stream. The modifications maynot completely eliminate the inefficiencies in allocation of themetadata stream, but the allocated metadata size will always beproportional to the allocated primary stream size and at worstlogarithmically related to the total primary stream size. Further, inthe circular logging case, the modifications allow the metadata to betruncated as the primary data stream is truncated.

Generally, the modifications differentiate the unallocated regions of asparse file that contain no real content from the allocated portions ofthe sparse file. Once differentiated, the file system can deallocate thenon-content portions. In one implementation, the file system creates anew one-way hash function g(x), as follows:

-   -   if x=0        -   g(x)=0    -   else        -   g(x)=h(x)            where h(x) is the standard one-way hash function specified            in the file format above. The hash function g(x) has the            property that data of all zeroes hashes to a hash value of            all zeroes.

One other modification is made to the leaf nodes of the tree structure408 that are associated with file blocks in unallocated ranges thatcontain no ciphertext. Each leaf node associated with such file blocksis modified such that the access value 604 (i.e., the encrypted hash(irrespective of the encryption key) of the nonexistent plaintext) isset to zero and the verification value 606 (i.e., the hash of thenonexistent ciphertext) is set to zero. Following this adjustment to theleaf nodes, the tree structure 408 is constructed using the hashfunction g(x) so higher-order intermediate nodes in the tree forzero-value leaf nodes will also be zero: g(0)=0.

In this manner, the file system need only allocate ranges for metadatablocks that contain non-zero data, which will be those that correspondto allocated primary stream data. Files that have large ranges ofunallocated blocks, such as circular-logging files, will havecorrespondingly large portions of zero-value metadata. The file systemcan then simply deallocate this metadata without changing its semantics.

The modifications discussed in this section do not compromise file-writesecurity. It may seem to, since write security rests on thenon-invertibility of the one-way hash function, and thenon-invertibility in the special case of zero-value data has beencompromised. However, all that has been forfeited is that an attackercan trivially compute the hash of zero-value data, but an attacker couldhave easily computed this value anyway simply by performing the hashcomputation.

Note that the stored hash value for unallocated ciphertext is zero,whereas the stored hash value for zero-value ciphertext is h(0), and thestored hash value for ciphertext corresponding to zero-value plaintextis h(E(0)). Thus, the tree of hashes distinguishes between all-zeroprimary-stream blocks and unallocated primary-stream blocks. Thisprevents an attacker from substituting one of these for the otherwithout detection by the directory servers or storage servers. Such asubstitution has the ability to affect application behavior, sinceapplications can query the set of allocated ranges in a file.

One potential downside is that the modifications for supporting sparsefiles do slightly compromise file-read security because it allows anattacker with no access to cryptographic keys to determine ranges in afile that are unallocated. However, this is not believed to result in asignificant information leak.

Conclusion

Although the invention has been described in language specific tostructural features and/or methodological steps, it is to be understoodthat the invention defined in the appended claims is not necessarilylimited to the specific features or steps described. Rather, thespecific features and steps are disclosed as preferred forms ofimplementing the claimed invention.

1. A method comprising: creating a primary data stream containing anencrypted file that is encrypted using at least one hash of somecontents of the file; and creating a metadata stream containinginformation pertaining to the encrypted file, the information includingdecryption capabilities used to decrypt the file and verificationcapabilities used to verify portions of the file without access todecryption keys.
 2. A distributed file system comprising: means forcreating a primary data stream containing an encrypted file that isencrypted using at least one hash of some contents of the file; andmeans for creating a metadata stream containing information pertainingto the encrypted file, the information including decryption capabilitiesused to decrypt the file and verification capabilities used to verifythe file.
 3. A distributed file system as recited in claim 2, whereinthe file in the primary stream comprises multiple encrypted blocks,where each block is hashed and encrypted using a hash value of the blockas an encryption key.
 4. A distributed file system as recited in claim2, wherein the means for creating the metadata stream comprises meansfor constructing leaf nodes for corresponding blocks, the leaf nodescontaining an access value used to decrypt the corresponding encryptedblock and a verification value used to verify the correspondingencrypted block.
 5. A data structure stored on a computer-readablemedium, comprising: a primary data stream containing an encrypted filecomposed of multiple encrypted blocks, each block being separatelyencrypted by a symmetric cipher that uses a hash of the block as anencryption key; a metadata stream containing information pertaining tothe encrypted file.
 6. A data structure as recited in claim 5, whereininformation includes decryption capabilities used to decrypt the file.7. A data structure as recited in claim 5, wherein information includesverification capabilities used to verify the file.
 8. A data structureas recited in claim 5, wherein the metadata stream comprises: a headerwith one or more fields that describe the encrypted file; and anindexing structure to index individual encrypted blocks.